really, QString isn't much longer to type than auto.

Any benefit to using an explicit type vs auto?

I believe CODING_GUIDELINES has enough explaination: https://github.com/qbittorrent/qBittorrent/blob/master/CODING_GUIDELINES.md#9-misc

Recommendations for modern C++ are to use auto quite liberally. We get no benefit from an explicit type here.

Recommendations for modern C++ are to use auto quite liberally.

Source?
IMO you're using auto a bit too liberal. auto is more like a shortcut, not be used like var in javascript.

From Item 5: Prefer auto to explicit type declarations in Effective Modern C++ by Scott Meyers:

Using [auto] saves typing, sure, but it also prevents correctness and performance issues that can bedevil manual type declaration ... There are thus several reasons to prefer auto over explicit type declarations ... The fact of the matter is that writing types explicitly often does little more than introduce opportunities for subtle errors, either in correctness or efficiency or both.

Ah, thank you, however I don't see he mentions anything about readability, a google search gives a handful of debates about readability of using auto.

When we discussed our rules about using auto keyword, we wanted to find a balance between faster code writing and readability. So don't abuse it, please.

I would change param name, but it breaks API compatibility...

I want your thoughts: we add an optional ids param that takes priority over the id param. Or we can change the name and bump the web api version.

We shouldn't produce incompatible changes so frequently if possible.
So maybe we should have some way to keep track of these "non-urgent" changes, and then make all the changes at once when we have the required changes?

Maybe keep the list of postponed changes near the API version declaration, e.g. "When your changes require increasing of minor version you should also apply the following:" and then list of changes.
What do you say? @Chocobo1?

What do you say? @Chocobo1?

I don't think I get your idea.

However I think the commit bumping API version should also include the api code changes, so it is possible to look up by reading git log.

I don't think I get your idea.

@Chocobo1, take this case for example.
Meaning of param 'id' was changed. Now it provide list of file IDs. It should cause changing of param name but it breaks API compatibility. It's really bad idea to make incompatible changes too frequently.
We can proceed to use old name for some time and just mark it for future changing.
When we make changes that cannot be made in a compatible way, we can add all pending changes with them.

We can proceed to use old name for some time and just mark it for future changing.

I don't object the idea, however I must say from my experience, revisiting an older code after some time takes much more time for the developer and outcome is usually not good enough quality.
If @Piccirello is interested, we could try it out in this case (experiment).

however I must say from my experience, revisiting an older code after some time takes much more time for the developer and outcome is usually not good enough quality.

So I suggest to keep list with postponed changes. We can have some instructions, where, what and how it should be changed. Or we can even have commented changes inplace.

Well, I'm not insisting. I just thought we shouldn't break API too often.

I would be interested, maybe maintaining a separate branch with breaking api changes that can be merged pre-minor version bump.

maybe maintaining a separate branch with breaking api changes that can be merged pre-minor version bump.

And have opened PR for it.
Let's try something!

const int id : fileIdsInts

From the coding guidelines:

Declarations for which one can gather enough information about the object interface (type) from its name or the usage pattern .. or the right part of the expression nicely fit here.

Seems we can gather enough info about the type from the variable name fileIdsInts.

The variable name does not matter. This paragraph means something completely different:

auto *varName = static_cast<RSS::Feed *>(rssItemPtr);

Or:

auto *session = BitTorrent::Session::instance();